home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1199 / 1627 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  3.1 KB
  1. Subject: yet more tfork() problems...
  2. Date: Sat, 18 Jun 94 13:20:16 +0100
  3. From: Torsten Scherer <itschere@TechFak.Uni-Bielefeld.DE>
  4.  
  5.  Hi fellas!
  6.  
  7.  Want to hear another story about problems with mintlibs tfork()? Yes?
  8. Here comes one:
  9.  
  10.  I wanted to write a program to read some data from stdin and perform some
  11. action with it. Since this action may be delayed due to several reasons,
  12. but I didn't want the main program to wait for this and didn't need any return
  13. code, I choose to do the action async with tfork(). Guess what I was trying
  14. to write? ;)
  15.  
  16.  So the main programs collects the data to a temporary file whose name is
  17. globally declared and just "exit(tfork(blabla, 0))". The `blabla' routine
  18. should just open the file again and do what I want it to do, maybe blocked,
  19. maybe not, doesn't matter for the async thread.
  20.  
  21.  What happened first, is that I opened another file with `fopen(name, "a")'
  22. to append the data to. It spuriously occured that there was complete trash
  23. in this file. It looked like the file buffer was flushed even when there
  24. wasn't anything in it. When I gave up buffered I/O but used open/write for
  25. the file I wanted to append the data to, *this* one worked ok.
  26.  
  27.  But the next thing is that the thread crashed with memory violation when
  28. trying to dereference a pointer pointing to zero. The only pointer left in
  29. the code was the filepointer for reading the tmpfile, which I was quite sure
  30. was opened correctly. It also didn't crash at any special position, sometimes
  31. it managed to write more, sometimes less, sometimes it even completely
  32. succeded (when there was very few data). But in 90% it crashed.
  33.  
  34.  After having spend several hours tracking this down and finding nothing, I
  35. became suspicious about the main program directly exiting after the tfork,
  36. and placed a `sleep(1)' at the beginning of the thread routine. Suddenly,
  37. everything worked perfectly right!
  38.  
  39.  That's where I remembered that it's said that tfork() "may cause problems
  40. with some library calls, notably malloc()". When looking at the library code,
  41. I saw that the main program explicitly closes all streams when exiting, and
  42. this probably also resets them to zero. This does mean nothing else than you
  43. can't use buffered I/O streams in a tforked thread if you can't guarantee
  44. that the child is going to exit *before* the main program, probably completely
  45. wiping out the initial reason of you chosing an async thread. :-(
  46.  
  47.  In my case, the thread can explicitly wait until the parent has exited, but
  48. for other problems, this may not work. Since working with file pointers seems
  49. to be quite ok, although access to static structures is not guarded by any
  50. kind of semaphore, I wondered if things might get better if one adds a `pid'
  51. field to the structure holding the pid of the program which has opened the
  52. stream, and only close those *we* explicitly own.
  53.  
  54.  Any ideas about that? To do it good, it would probably require some kind of
  55. semaphore... And all this only because of the non-working vfork...
  56.  
  57. ciao,
  58. TeSche
  59. -- 
  60. Torsten Scherer (TeSche, Schiller...)
  61. Faculty of Technology, University of Bielefeld, Germany, Europe, Earth...
  62. | Use any of "finger itschere@129.70.131.2-15" for adresses and more.|
  63. | Last updated: 14. April 1994.|
  64.